Flight plan recommendation based on analysis of airspace voxels

ABSTRACT

A device can receive information that identifies an airspace voxel that represents a three-dimensional portion of airspace during a particular time period. The device can associate one or more airspace parameters with the airspace voxel. The one or more airspace parameters can represent one or more conditions that relate to flight through the airspace voxel during the particular time period. The device can receive one or more flight parameters regarding a potential flight plan of an aircraft through a plurality of airspace voxels, including the airspace voxel, during the particular time period. The device can analyze the one or more flight parameters and a plurality of airspace parameters, associated with the plurality of airspace voxels, using one or more airspace rules. The device can output a recommendation regarding the potential flight plan based on analyzing the one or more flight parameters and the plurality of airspace parameters.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/725,012, filed Oct. 4, 2017, which is incorporated herein byreference.

BACKGROUND

An unmanned aerial vehicle (UAV), commonly known as a drone, is anaircraft without a human pilot aboard. The flight of UAVs can operatewith various degrees of autonomy (e.g., under remote control by a humanoperator, autonomously by onboard computers, etc.). UAVs can be used fora variety of purposes including logistics (e.g., delivering cargo),aerial photography, data collection, combat, and reconnaissance.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C are diagrams of an overview of an example implementationdescribed herein;

FIG. 2 is a diagram of an example environment in which systems and/ormethods, described herein, can be implemented;

FIG. 3 is a diagram of example components of one or more devices of FIG.2; and

FIG. 4 is a flow chart of an example process for flight planrecommendation based on analysis of airspace voxels.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description of example implementations refers tothe accompanying drawings. The same reference numbers in differentdrawings may identify the same or similar elements.

As the use of unmanned aerial vehicles (UAVs) increases, managingairspace for the flight of UAVs will become increasingly complex. Forexample, a UAV flight plan must account for a large number of changingconditions, such as regulatory conditions, flight plans of other UAVsand manned aerial vehicles, weather and other environmental conditions,as well as characteristics of different UAVs. As such, management of UAVflights can require the analysis of hundreds, thousands, millions,billions or more data points, particularly as hundreds, thousands, ormore UAVs are deployed.

Implementations described herein can divide airspace into airspacevoxels that each represent a three-dimensional portion of airspaceduring a particular time period. This can result in the creation ofthousands, millions, or more voxels. An airspace voxel can be associatedwith airspace parameters that represent conditions relating to flightthrough the airspace voxel during a particular time period. Theseairspace voxels and associated airspace parameters can be used toanalyze and provide recommendations regarding flight plans for tens,hundreds, thousands, millions, or more UAVs to consistently generatesafe, efficient flight plans. Such flight plans can be analyzed before aUAV flight (e.g., pre-flight), or can be generated in real-time viadirect communication with the UAV while the UAV is in flight. In thisway, a large quantity of UAV flight plans can be improved or optimizedto increase flight safety, reduce accidents, conserve UAV energy (e.g.,battery power, fuel, etc.), reduce flight time, and/or the like.

FIGS. 1A-1C are diagrams of an overview of an example implementation 100described herein. As shown in FIG. 1A, example implementation 100 caninclude a UAV management device and one or more source devices. As shownby reference number 110, the UAV management device can generate airspacevoxels. Each airspace voxel can represent a three-dimensional portion ofairspace during a particular time period (e.g., 1 second, 10 seconds, 30seconds, 1 minute, 5 minutes, etc.). In some implementations, the UAVmanagement device can generate the voxels. Additionally, oralternatively, the UAV management device can receive informationidentifying the voxels from another device.

As further shown in FIG. 1A, and by reference number 120, the UAVmanagement device can receive airspace parameters from one or moresource devices (e.g., servers, end user computers, etc.). An airspaceparameter can represent a condition relating to flight through a voxel(e.g., during a particular time period), such as a regulatory condition(e.g., a flight restriction, a zoning law, a noise ordinance, a privacyordinance, etc.), an environment condition (e.g., weather, sunlight,time of day, etc.), a voxel occupancy condition (e.g., whether anotheraircraft will be located in the voxel during a time period, a quantityof aircraft that will be located in the voxel during the time period, asize, weight, or class of those aircraft, etc.), and/or the like.Additional details regarding these conditions are described elsewhereherein.

As further shown in FIG. 1A, and by reference number 130, the UAVmanagement device can store a data structure that associates voxels andairspace parameters. For example, airspace voxel A (at time 1) can beassociated with a first set of one or more airspace parameters, airspacevoxel A (at time 2) can be associated with a second set of one or moreairspace parameters, etc., airspace voxel B (at time 1) can beassociated with an n^(th) set of one or more airspace parameters, and soon. The data structure can include a massive amount of data (e.g., bigdata), which the UAV management device can use to analyze UAV flightplans, as described below.

As shown in FIG. 1B, example implementation 100 can further include aclient device. As shown by reference number 140, the UAV managementdevice can receive one or more flight parameters from the client device.For example, a user can interact with the client device to request aflight plan for a UAV, and the flight plan can include, for example, adeparture location and an arrival location, as well as flightparameters.

The flight parameters can include aircraft parameters (e.g., a size,weight, or class of the UAV, an airworthiness of the UAV, a payload ofthe UAV, an amount of noise generated by the UAV, etc.), pilotparameters (e.g., a type of license that the UAV pilot has, anexperience level of the UAV pilot, qualifications of the UAV pilot,etc.), analysis parameters (e.g., a risk, cost, time, or networktolerance associated with the flight plan), and/or the like. Additionaldetails regarding flight plans and flight parameters are describedelsewhere herein.

As further shown in FIG. 1B, and by reference number 150, the UAVmanagement device can analyze the flight parameters and airspaceparameters using airspace rules. The airspace rules can be global rulesthat apply to all aircraft (e.g., government regulations), individualUAV rules that apply to a particular UAV, group UAV rules that apply toa group of UAVs (e.g., UAVs owned by the same owner, UAVs that are thesame class, etc.), pilot rules that apply to a particular pilot or aparticular type of pilot license, and/or the like. Additional detailsregarding airspace rules are described elsewhere herein.

As shown in FIG. 1C, and by reference number 160, the UAV managementdevice can generate a recommendation based on the analysis describedabove. The recommendation can include, for example, a recommended flightplan for a UAV (as shown), a rejection of a proposed flight plan, anapproval of a proposed flight plan, or the like. Additionally, oralternatively, the recommendation can include a request for user inputto reject or approve the flight plan (e.g., and the UAV managementdevice can provide the user input to a machine learning algorithm toautomate such decisions in the future), and/or the like.

As further shown in FIG. 1C, and by reference number 170, the UAVmanagement device can provide the recommendation to the client device.For example, as shown, the recommendation can include a recommendedflight plan from the departure location (at voxel B) to the arrivallocation (at voxel H). In this case, the recommended flight plan canprovide information to instruct and/or control the UAV to depart fromvoxel B, and then to proceed to voxel D rather than voxel A becausevoxel A has a high occupancy. Continuing with the example, therecommended flight plan can provide information to instruct and/orcontrol the UAV to avoid voxel F (e.g., to prevent violation of a noiseordinance associated with voxel F), and to proceed from voxel D to voxelC to voxel E to voxel G to the arrival location at voxel H.

The above flight plan description is provided merely as an example, andother examples can differ from what was described. In practice, the UAVmanagement device can analyze a large quantity (e.g., hundreds,thousands, millions, etc.) of data points for a large quantity of UAVsto generate recommended flight plans for one or more UAVs. Furthermore,the UAV management device can perform the analysis in real-time as datais received from a UAV during flight of the UAV (e.g., in-flight), suchas to alter a flight plan due to changing conditions. In this way, theUAV management device can increase flight safety, reduce accidents,conserve UAV energy, reduce flight time, and/or the like.

As indicated above, FIGS. 1A-1C are provided merely as an example. Otherexamples are possible and can differ from what was described with regardto FIGS. 1A-1C.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods, described herein, can be implemented. As shown in FIG.2, environment 200 can include one or more unmanned aerial vehicles(UAVs) 210 (hereinafter referred to individually as “UAV 210,” andcollectively as “UAVs 210”), a radio access network (RAN) 220, one ormore base stations 230 (hereinafter referred to individually as “basestation 230,” and collectively as “base stations 230”), a core network240, an external network 250, a UAV management device 260, one or moresource devices 270, and one or more client devices 280. Devices ofenvironment 200 can interconnect via wired connections, wirelessconnections, or a combination of wired and wireless connections.

UAV 210 includes an aircraft without a human pilot aboard, and can alsobe referred to as an unmanned aircraft (UA), a drone, a remotely pilotedvehicle (RPV), a remotely piloted aircraft (RPA), or a remotely operatedaircraft (ROA). UAV 210 can have a variety of shapes, sizes,configurations, characteristics, etc. for a variety of purposes andapplications. In some implementations, UAV 210 can include one or moresensors, such as an electromagnetic spectrum sensor (e.g., visualspectrum, infrared, or near infrared cameras, radar systems, etc.), abiological sensor, a temperature sensor, a chemical sensor, and/or thelike. In some implementations, UAV 210 can include one or morecomponents for communicating with base station(s) 230. Additionally, oralternatively, UAV 210 can transmit information to and/or can receiveinformation from UAV management device 260, such as sensor data, flightplan information, and/or the like. Such information can be communicatedvia base station 230, core network 240, and/or external network 250.

RAN 220 includes one or more radio access networks such as, for example,a code division multiple access (CDMA) RAN, a time division multipleaccess (TDMA) RAN, a frequency division multiple access (FDMA) RAN, auniversal terrestrial radio access network (UTRAN), an evolved UTRAN(E-UTRAN) (e.g., an LTE RAN, an LTE-Advanced (LTE-A) RAN, anLTE-unlicensed (LTE-U) RAN, etc.), or the like. RAN 220 can include oneor more base stations 230 that provide access for UAVs 210 to corenetwork 240.

Base station 230 includes one or more devices capable of transferringtraffic, such as audio, video, text, and/or other traffic, destined forand/or received from UAV 210. In some implementations, base station 230can include an evolved NodeB (eNB) associated with an LTE radio accessnetwork (RAN) that receives traffic from and/or sends traffic to UAVmanagement device 260 and/or client device 280 via core network 240.Additionally, or alternatively, one or more base stations 230 can beassociated with a RAN that is not associated with the LTE network. Basestation 230 can send traffic to and/or receive traffic from UAV 210 viaan air interface. Base station(s) 230 can include different types ofbase stations, such as a macro cell base station or a small cell basestation, such as a micro cell base station, a pico cell base station,and/or a femto cell base station. A macro cell base station can cover arelatively large geographic area (e.g., several kilometers in radius). Asmall cell base station can be a lower-powered base station, as comparedwith a macro cell base station that can operate in the same or different(e.g., licensed, unlicensed, etc.) frequency bands as macro cell basestations.

Core network 240 includes a network that enables communications betweenRAN 220 (e.g., base station(s) 230) and one or more devices and/ornetworks connected to core network 240. For example, core network 240can include an evolved packet core (EPC). Core network 240 can includeone or more mobility management entities (MMEs), one or more servinggateways (SGWs), and one or more packet data network gateways (PGWs)that together provide mobility functions for UAVs 210 and enable UAVs210 to communicate with other devices of environment 200.

External network 250 includes one or more wired and/or wirelessnetworks. For example, external network 250 can include a cellularnetwork (e.g., a long-term evolution (LTE) network, a code divisionmultiple access (CDMA) network, a 3G network, a 4G network, a 5Gnetwork, another type of advanced generated network, etc.), a publicland mobile network (PLMN), a local area network (LAN), a wide areanetwork (WAN), a metropolitan area network (MAN), a telephone network(e.g., the Public Switched Telephone Network (PSTN)), a private network,an ad hoc network, an intranet, the Internet, a fiber optic-basednetwork, a cloud computing network, or the like, and/or a combination ofthese or other types of networks.

UAV management device 260 includes one or more devices for managing UAVs210 and/or flight plans for UAVs 210. For example, UAV management device260 can include a server, a desktop computer, a laptop computer, or asimilar device. In some implementations, UAV management device 260 cancommunicate with one or more devices of environment 200 (e.g., UAV 210,source device 270, client device 280, etc.), and to receive informationto be used to analyze and/or recommend flight plans for UAVs 210, and/orto provide a recommendation. In some implementations, UAV managementdevice 260 can permit control of UAV(s) 210 by a user who interacts withclient device 280 to access UAV management device 260. In someimplementations, UAV management device 260 can be included in a datacenter, a cloud computing environment, a server farm, or the like, whichcan include multiple UAV management devices 260. While shown as externalfrom core network 240, in some implementations, UAV management device260 can reside within core network 240.

Source device 270 includes one or more devices that act as data sourcesfor information to be used by UAV management device 260 to analyzeand/or recommend a flight plan. For example, source device 270 caninclude a server (e.g., in a data center, a cloud computing environment,etc.) and/or a similar type of device. In some implementations, sourcedevice 270 can store regulatory information, weather information, flightplan information, and/or the like.

Client device 280 includes one or more devices capable of providinginformation to be used by UAV management device 260 to analyze and/orrecommend a flight plan. For example, client device 280 can include adesktop computer, a laptop computer, a tablet computer, a mobile phone,or a similar device. In some implementations, a user can interact withclient device 280 to request a flight plan analysis and/orrecommendation for a UAV 210 from UAV management device 260. UAVmanagement device 260 can perform the analysis, and can provide therecommendation to client device 280.

The number and arrangement of devices and networks shown in FIG. 2 areprovided as an example. In practice, there can be additional devicesand/or networks, fewer devices and/or networks, different devices and/ornetworks, or differently arranged devices and/or networks than thoseshown in FIG. 2. Furthermore, two or more devices shown in FIG. 2 can beimplemented within a single device, or a single device shown in FIG. 2can be implemented as multiple, distributed devices. Additionally, oralternatively, a set of devices (e.g., one or more devices) ofenvironment 200 can perform one or more functions described as beingperformed by another set of devices of environment 200.

FIG. 3 is a diagram of example components of a device 300. Device 300can correspond to UAV 210, base station 230, UAV management device 260,source device 270, and/or client device 280. In some implementations,UAV 210, base station 230, UAV management device 260, source device 270,and/or client device 280 can include one or more devices 300 and/or oneor more components of device 300. As shown in FIG. 3, device 300 caninclude a bus 310, a processor 320, a memory 330, a storage component340, an input component 350, an output component 360, and acommunication interface 370.

Bus 310 includes a component that permits communication among thecomponents of device 300. Processor 320 is implemented in hardware,firmware, or a combination of hardware and software. Processor 320 is acentral processing unit (CPU), a graphics processing unit (GPU), anaccelerated processing unit (APU), a microprocessor, a microcontroller,a digital signal processor, a field-programmable gate array (FPGA), anapplication-specific integrated circuit (ASIC), or another type ofprocessing component. In some implementations, processor 320 includesone or more processors capable of being programmed to perform afunction. Memory 330 includes a random access memory (RAM), a read onlymemory (ROM), and/or another type of dynamic or static storage device(e.g., a flash memory, a magnetic memory, and/or an optical memory) thatstores information and/or instructions for use by processor 320.

Storage component 340 stores information and/or software related to theoperation and use of device 300. For example, storage component 340 caninclude a hard disk (e.g., a magnetic disk, an optical disk, amagneto-optic disk, and/or a solid state disk), a compact disc (CD), adigital versatile disc (DVD), a floppy disk, a cartridge, a magnetictape, and/or another type of non-transitory computer-readable medium,along with a corresponding drive.

Input component 350 includes a component that permits device 300 toreceive information, such as via user input (e.g., a touch screendisplay, a keyboard, a keypad, a mouse, a button, a switch, and/or amicrophone). Additionally, or alternatively, input component 350 caninclude a sensor for sensing information (e.g., a global positioningsystem (GPS) component, an accelerometer, a gyroscope, and/or anactuator). Output component 360 includes a component that providesoutput information from device 300 (e.g., a display, a speaker, and/orone or more light-emitting diodes (LEDs)).

Communication interface 370 includes a transceiver-like component (e.g.,a transceiver and/or a separate receiver and transmitter) that enablesdevice 300 to communicate with other devices, such as via a wiredconnection, a wireless connection, or a combination of wired andwireless connections. Communication interface 370 can permit device 300to receive information from another device and/or provide information toanother device. For example, communication interface 370 can include anEthernet interface, an optical interface, a coaxial interface, aninfrared interface, a radio frequency (RF) interface, a universal serialbus (USB) interface, a Wi-Fi interface, a cellular network interface, orthe like.

Device 300 can perform one or more processes described herein. Device300 can perform these processes in response to processor 320 executingsoftware instructions stored by a non-transitory computer-readablemedium, such as memory 330 and/or storage component 340. Acomputer-readable medium is defined herein as a non-transitory memorydevice. A memory device includes memory space within a single physicalstorage device or memory space spread across multiple physical storagedevices.

Software instructions can be read into memory 330 and/or storagecomponent 340 from another computer-readable medium or from anotherdevice via communication interface 370. When executed, softwareinstructions stored in memory 330 and/or storage component 340 can causeprocessor 320 to perform one or more processes described herein.Additionally, or alternatively, hardwired circuitry can be used in placeof or in combination with software instructions to perform one or moreprocesses described herein. Thus, implementations described herein arenot limited to any specific combination of hardware circuitry andsoftware.

The number and arrangement of components shown in FIG. 3 are provided asan example. In practice, device 300 can include additional components,fewer components, different components, or differently arrangedcomponents than those shown in FIG. 3. Additionally, or alternatively, aset of components (e.g., one or more components) of device 300 canperform one or more functions described as being performed by anotherset of components of device 300.

FIG. 4 is a flow chart of an example process 400 for flight planrecommendation based on analysis of airspace voxels. In someimplementations, one or more process blocks of FIG. 4 can be performedby UAV management device 260. In some implementations, one or moreprocess blocks of FIG. 4 can be performed by another device or a groupof devices separate from or including UAV management device 260, such asUAV 210, base station 230, source device 270, and/or client device 280.

As shown in FIG. 4, process 400 can include receiving information thatidentifies an airspace voxel that represents a three-dimensional portionof airspace during a particular time period (block 410). For example,UAV management device 260 can receive the information that identifies anairspace voxel.

In some implementations, an airspace voxel can represent athree-dimensional portion of airspace. In some implementations, theairspace voxel can be associated with a particular time period. In thisway, the same three-dimensional portion of airspace can be associatedwith different parameters at different times, as conditions in theairspace change. In some implementations, a time period can havedifferent granularities, such as an indefinite period, one or more days,one or more hours, one or more minutes, one or more seconds, or thelike.

In some implementations, UAV management device 260 can divide airspaceinto numerous (thousands, millions, etc.) airspace voxels. In someimplementations, the airspace voxels can be uniform or non-uniform insize and shape. In some implementations, UAV management device 260 canrepresent each of the airspace voxels using a group of coordinates(e.g., latitude, longitude, elevation) that define the dimensions ofeach airspace voxel. In some implementations, UAV management device 260can receive voxels as input (e.g., user input), or can generate voxels,and can store a representation of voxels (e.g., in a data structure).Additionally, or alternatively, different UAV management devices 260 canmanage UAV traffic at different scales, such as a global voxel scale tomanage long-distance flights, a regional voxel scale to manage flightswithin a particular geographic region, a city-wide scale to manage urbanflights, and/or the like. In some implementations, the number of voxelsmanaged by UAV management device 260 can vary based on the size of avoxel, a scale of the UAV network managed by the UAV management device260, and/or the like.

As further shown in FIG. 4, process 400 can include associating one ormore airspace parameters with the airspace voxel (block 420). Forexample, UAV management device 260 can associate the one or moreairspace parameters with the airspace voxel.

In some implementations, an airspace parameter can represent one or moreconditions that relate to flight through the airspace voxel. In somecases, an airspace parameter can be a static parameter that is valid forall time periods, such as a permanent flight restriction over importantgovernment buildings (e.g., The White House). In some cases, an airspaceparameter can be dynamic, and can have different values during differenttime periods, such as a noise ordinance that is valid only at night.

In some implementations, UAV management device 260 can receive airspaceparameters as input (e.g., user input), can receive or retrieve theairspace parameters from one or more source devices 270 (e.g., adatabase of regulatory conditions, etc.), and/or the like. In someimplementations, UAV management device 260 can associate airspaceparameters with airspace voxels and/or time periods by storing, in adata structure, an indication of a relationship between the airspaceparameters, airspace voxels, and/or time periods.

In some implementations, an airspace parameter can represent one or moreconditions that include one or more regulatory conditions (e.g.,government regulations regarding flight). For example, a regulatorycondition can include a flight restriction in an airspace voxel. In thiscase, the regulatory condition can include a permanent flightrestriction (e.g., a class of controlled airspace or uncontrolledairspace), can include a temporary flight restriction (e.g., due to afire, a police investigation, travel of important government officials,etc.), and/or the like.

As another example, a regulatory condition can include a zoning lawassociated with an airspace voxel (e.g., whether the ground beneath avoxel is valid for takeoff/landing). As yet another example, aregulatory condition can include a noise ordinance associated with anairspace voxel (e.g., an amount of noise permitted in the voxel orground beneath the voxel). As still another example, a regulatorycondition can include a privacy ordinance associated with an airspacevoxel (e.g., a restriction on surveillance).

In some implementations, an airspace parameter can represent one or moreconditions that include one or more environmental conditions. Forexample, an environmental condition can include weather in an airspacevoxel (e.g., wind, rain, snow, sleet, hail, fog, clouds, sun,temperature, humidity, barometric pressure, etc.). In this case, theenvironmental condition can be based on a weather forecast for theairspace voxel, can be based on sensor data gathered from one or moresensors of one or more UAVs 210, or the like. Additionally, oralternatively, an environmental condition can include an amount ofsunlight (e.g., which can impact collision detection), a time of day(e.g., which can impact an amount of sunlight, temperature, or otherconditions), or the like.

In some implementations, an airspace parameter can represent one or moreconditions that include one or more voxel occupancy conditions. Forexample, a voxel occupancy condition can identify whether anotheraircraft is to be located in the airspace voxel, such as according to aschedule, flight plans, etc., or according to sensor data obtained fromone or more aircraft. As another example, a voxel occupancy conditioncan include a quantity of aircraft to be located in the airspace voxel,can include one or more characteristics of aircraft to be located in theairspace voxel (e.g., size(s), weight(s), class(es), etc. of theaircraft), or the like.

In some implementations, an airspace parameter can represent one or moreconditions that include one or more ground conditions. For example, aground condition can relate to objects on the ground beneath an airspacevoxel (e.g., fire trucks, ladders, cranes, people, etc.). Additionally,or alternatively, UAV management device 260 and/or source device(s) 270can obtain information, identifying the ground conditions, from adatabase and/or from sensor data of an aircraft.

As further shown in FIG. 4, process 400 can include receiving one ormore flight parameters regarding a potential flight plan of an aircraftthrough a plurality of airspace voxels, including the airspace voxel,during the particular time period (block 430). For example, UAVmanagement device 260 can receive one or more flight parameters (e.g.,from client device 280 via external network 250) regarding a potentialflight plan of an aircraft through a plurality of airspace voxels,including the airspace voxel, during the particular time period.

In some implementations, a flight parameter can relate to a potentialflight plan of an aircraft. In some implementations, a flight plan caninclude a departure location (e.g., ground beneath a first voxel), anarrival location (e.g., ground beneath a second voxel), and/or multipledeparture locations and arrival locations (for multiple deliveries ofpackages, for example). Additionally, or alternatively, a flight plancan include voxels to be traversed by the aircraft, an order or sequencein which the voxels are to be traversed, an overall flight time, aflight time per voxel (e.g., an amount of time to spend in a voxel), anoverall flight speed, a flight speed per voxel, and/or the like.

In some implementations, a flight parameter can include one or moreaircraft parameters relating to characteristics of the aircraft. Forexample, a flight parameter can include a size, weight, or class of theaircraft (e.g., the aircraft for which a recommendation is to begenerated). As another example, a flight parameter can includeinformation that represents an airworthiness of the aircraft (e.g., dueto maintenance, age, etc.). As yet another example, a flight parametercan include information that represents a payload of the aircraft (e.g.,a type of payload, an indication of a value or a fragility of thepayload, a weight of the payload, sensitivity level of payload,resolution of a camera on UAV 210, etc.). As still another example, aflight parameter can include information that represents an amount ofnoise generated by the aircraft (e.g., which can be taken into accountfor a noise ordinance).

In some implementations, a flight parameter can include one or morepilot parameters relating to characteristics of the pilot of theaircraft. For example, the pilot parameters can include information thatindicates whether the pilot is registered to pilot UAVs in the voxel(e.g., as per local government regulations). As another example, thepilot parameters can include information that represents qualificationsof the pilot, experience of the pilot (e.g., number of flights, numberof years, etc.), a type of pilot's license that the pilot has, or thelike.

In some implementations, a flight parameter can include one or moreanalysis parameters relating to a preference of an entity (e.g., owner,pilot, etc.) associated with the aircraft. For example, the analysisparameters can include information that represents a risk toleranceassociated with the aircraft or the potential flight plan (e.g., lowcost drones or payloads can have a higher risk tolerance for potentialaccidents than high cost drones or payloads). As another example, theanalysis parameters can include information that represents a costtolerance associated with the aircraft or the potential flight plan(e.g., certain flight plans can require more expensive pilots, canrequire more expensive licenses, etc.). As yet another example, theanalysis parameters can include information that represents a timetolerance associated with the aircraft or the potential flight plan(e.g., the entity can have a total flight time requirement fromdeparture to arrival). As yet another example, the analysis parameterscan include information that represents a network tolerance associatedwith the aircraft or the potential flight plan (e.g., a system ornetwork with infrastructure that supports flight operations can havethresholds associated with cost to the system or network, risk to thesystem or network, time factors associated with the system or network,etc.).

As further shown in FIG. 4, process 400 can include analyzing the one ormore flight parameters and a plurality of airspace parameters,associated with the plurality of airspace voxels, using one or moreairspace rules (block 440). For example, UAV management device 260 cananalyze the one or more flight parameters and a plurality of airspaceparameters, associated with the plurality of airspace voxels, using oneor more airspace rules.

In some implementations, UAV management device 260 can use the airspacerules to analyze flight parameter(s) and airspace parameter(s) ofairspace voxels associated with a potential flight plan. For example,the airspace rules can be global rules that apply to all aircraft (e.g.,government regulations), individual UAV rules that apply to a particularUAV 210, group UAV rules that apply to a group of UAVs 210 (e.g., UAVsowned by the same owner, UAVs that are the same class, etc.), pilotrules that apply to a particular pilot or a particular type of pilotlicense, and/or the like.

In some implementations, UAV management device 260 can analyze a largequantity of flight plans, taking into account travel through differentsequences of voxels from departure location to arrival location. In somecases, UAV management device 260 can apply one or more rules indicatingthat a UAV cannot traverse a same voxel more than once, can apply one ormore rules indicating that a UAV can traverse a same voxel more thanonce (e.g., backtracking to avoid collision), and/or can apply one ormore rules indicating that a UAV is to hover, adjust speed, and/or thelike.

In some implementations, UAV management device 260 can generate scoresfor flight plans that take into account one or more of a risk factor(e.g., potential for collision or accident), a cost factor (e.g., energyconsumption), a time factor (e.g., time of travel), a network factor(e.g., a risk, cost, or time factor to a network operator withinfrastructure that support flight operations), and/or the like. In thiscase, UAV management device 260 can apply different weights to differentfactors based on preferences of an entity associated with aircraft. Insome cases, UAV management device 260 can automatically accept a flightplan if the score satisfies a first threshold. Similarly, UAV managementdevice 260 can automatically reject a flight plan if the score does notsatisfy a second threshold.

In some cases, UAV management device 260 can calculate a voxel score forindividual voxels, and can combine voxels along a flight path from adeparture location to an arrival location (e.g., a summation of allvoxels, an average voxel score, a maximum voxel score, etc.) tocalculate an overall score for the flight path. In some implementations,if a score is between thresholds, UAV management device 260 can outputthe score and/or factors that contributed to the score, and can requestoperator input as to whether to accept the flight plan. In someimplementations, UAV management device 260 can base scores, airspacerules, and/or recommendations not only on the aircraft for which theflight plan is being determined, but also on other aircraft expected tobe in the voxels of the flight plan.

For some airspace rules, UAV management device 260 may not permit therules to be violated, such as travel through restricted airspace. Forsome airspace rules, UAV management device 260 may not permit the rulesto be violated for a particular entity, such as travel through a voxelwith more than a threshold quantity of aircraft. For some airspacerules, UAV management device 260 may permit the rules to be violated insome situations, based on weighing a number of factors.

As an example of an airspace rule, UAV management device 260 can preventflight through a voxel if the voxel is in restricted airspace, or canrestrict flight to a certain class of aircraft (e.g., military). In thiscase, the restriction could be a permanent restriction or a temporaryrestriction. For example, UAV management device 260 can periodicallypull information from a database that stores information regardingtemporary restrictions.

As still another example of an airspace rule, UAV management device 260can restrict takeoff and landing on ground beneath voxels based onzoning laws that define valid takeoff and landing zones. As anotherexample of an airspace rule, UAV management device 260 can compare anoise level (e.g., in decibels) of aircraft to a noise level permittedby a noise ordinance associated with a particular voxel. In this case,UAV management device 260 can compare a noise level of individualaircraft, or can aggregate information for all aircraft expected to bein the particular voxel to determine whether an additional aircraft ispermitted. If a noise ordinance is associated with ground beneath avoxel, UAV management device 260 can adjust the noise level based on thedistance from the voxel to the ground.

As yet another example of an airspace rule, if aircraft payload includesa camera (e.g., for surveillance, mapping, etc.), UAV management device260 can restrict flight in certain voxels based on privacy ordinances.In this case, UAV management device 260 can compare a resolution of thecamera to a resolution permitted by a privacy ordinance to determinewhether to permit flight through the voxel.

As still another example of an airspace rule, UAV management device 260can allow or prevent flight through a voxel or modify a voxel score(e.g., a risk score) if wind speed satisfies a threshold, if an amountof rain, snow, sleet, hail, fog, clouds, lightning, sunlight, etc. inthe voxel satisfies a threshold, if a temperature, humidity, barometricpressure, etc. satisfies a threshold (e.g., a temperature above a firstthreshold or below a second threshold, etc.), and/or the like.

As another example of an airspace rule, UAV management device 260 canallow or prevent flight through a voxel or modify a voxel score based ontime of day. For example, there can be different conditions at differenttimes of day, a flight can be safer during the day than at night becausevisibility is higher, or the like.

As yet another example of an airspace rule, UAV management device 260can allow or prevent flight through a voxel or modify a voxel scorebased on voxel occupancy, such as based on whether another aircraft isto be located in the voxel, a quantity of aircraft to be located in thevoxel, characteristics of one or more aircraft to be located in thevoxel (e.g., size, class, weight, etc.), or the like.

As still another example of an airspace rule, UAV management device 260can allow or prevent flight through a voxel or modify a voxel scorebased on a ground condition relating to an object on the ground beneaththe voxel. For example, UAV management device 260 can prevent flight orhigher risk if there is a crane on the ground beneath a voxel, if thereare a threshold quantity of people on the ground beneath a voxel, or thelike. In this case, the airspace rule can also be based on aircraftparameters (e.g., UAV management device 260 can prevent flying abovepeople when the payload is heavy).

As another example of an airspace rule, UAV management device 260 canallow or prevent flight through a voxel or modify a voxel score based oncharacteristics of the aircraft. As a specific example, UAV managementdevice 260 can permit a small aircraft to fly through a voxel if thereare two other aircraft to be located in the voxel, while a largeaircraft may not be permitted to fly through the voxel. As anotherspecific example, a more airworthy aircraft can have a higher risktolerance than a less airworthy aircraft, and UAV management device 260can permit the more airworthy aircraft to fly through a voxel with ahigher risk score (e.g., due to bad weather) than a less airworthyaircraft. As yet another specific example, an aircraft with a morefragile or valuable payload can have a lower risk tolerance than anaircraft with a less fragile or less valuable payload. Similarly, a moreexpensive aircraft can have a lower risk tolerance than a less expensiveaircraft (e.g., because the more expensive aircraft will be more costlyto replace in the event of an accident).

As yet another example of an airspace rule, UAV management device 260can allow or prevent flight through a voxel or modify a voxel scorebased on characteristics of a pilot of UAV 210. For example, UAVmanagement device 260 can permit a pilot with a higher score (e.g., dueto more experience, a higher class of license, more qualifications,etc.) to fly a UAV through a voxel with a higher risk score as comparedto a pilot with a lower score. As another example, UAV management device260 can require a pilot to be licensed or registered with a governmentor municipality that controls the airspace voxel.

In some implementations, UAV management device 260 can perform theanalysis to generate a binary score based on applying one or moreairspace rules (e.g., indicating UAV 210 is permitted or not permittedto fly through voxel(s)). For example, the binary score can indicate UAV210 is not permitted to fly through a voxel that is part of restrictedairspace. Additionally, or alternatively, UAV management device 260 canperform the analysis to generate a non-binary score based on applyingone or more airspace rules. For example, UAV management device 260 cangenerate a numeric score, a labeled score (e.g., green, yellow, red, orhigh, medium, low), and/or the like.

In some implementations, UAV management device 260 can generate one ormore category scores, such as a risk score, a cost score, a time score,a network score, and/or the like. In some cases, UAV management device260 can combine two or more category scores to generate an overall score(e.g., for a voxel or a group of voxels included in a flight plan). Inthis case, UAV management device 260 can apply weights to differentcategory scores based on user input indicating the importance of thedifferent categories.

As further shown in FIG. 4, process 400 can include outputting arecommendation regarding the potential flight plan based on analyzingthe one or more flight parameters and the plurality of airspaceparameters (block 450). For example, UAV management device 260 canoutput a recommendation (e.g., to client device 280 via external network250) regarding the potential flight plan based on analyzing the one ormore flight parameters and the plurality of airspace parameters.

In some implementations, UAV management device 260 can determine therecommendation based on the analysis described above, such as based onthe binary score, non-binary score, or the like. In some cases, therecommendation can include automatic approval or rejection of a flightplan (e.g., based on a binary score and/or based on comparing anon-binary score to a threshold). In some cases, UAV management device260 can transmit approval or rejection to UAV 210 (e.g., which can belocated at a departure location, or can store a schedule of flightplans), and can be used by UAV 210 for a flight.

Additionally, or alternatively, UAV management device 260 can providethe recommendation to client device 280 of an entity associated with UAV210 (e.g., pilot, owner, shipper, user, etc.). In some implementations,the recommendation can include a recommendation of whether to approve orreject a flight plan. In this case, the entity can interact with clientdevice 280 to provide input on whether to approve or reject therecommendation, and can send that information to UAV management device260. In some implementations, UAV management device 260 can use thisuser input as feedback for a machine learning algorithm, and canautomate future decisions based on machine learning (e.g., for thisentity, similar entities, and/or other entities).

In some implementations, the recommendation can include a recommendedflight plan. In this case, UAV management device 260 can determine theflight plan based on a best overall score for the flight plan, and/orbased on individual scores (e.g., a risk score, a cost score, a timescore, a network score, etc.) for the flight plan (e.g., based oncombining scores for voxels included in the flight plan).

In some implementations, the recommendation can include multiple flightplans with an option to select one (e.g., least risky vs. least costlyvs. shortest flight time vs. least cost to the network, or somecombination thereof, or top 3 scores with risk score, cost score, timescore, network score, etc.). Additionally, or alternatively, UAVmanagement device 260 can indicate reasons for the scores or potentialrisk factors (e.g., high wind, high occupancy, etc.). In some cases, UAVmanagement device 260 can output one or more parameters associated withthe voxels so that the user can see conditions along the flight plan.

In some cases, UAV management device 260 can provide the recommendationpre-flight, and can use the recommendation to schedule a flight of UAV210. In some cases, UAV management device 260 can provide therecommendation in-flight. For example, UAV 210 can use sensors to detecta trigger condition (e.g., high occupancy, bad weather, etc.), and canrequest an update to a flight plan. In this case, UAV management device260 can receive the request, can execute the analysis, and can return arecommendation to UAV 210 in flight (e.g., via a base station incommunication with UAV 210).

Additionally, or alternatively, UAV management device 260 can monitorairspace by receiving real-time information regarding UAVs 210 (e.g.,locations, characteristics, sensor data, payloads, maintenance records,etc.), weather, events, regulatory changes, etc., and can proactivelysend revised flight plans to UAVs 210. If approved, UAV managementdevice 260 can update stored information. For example, UAV managementdevice 260 can update voxel occupancy information that indicates aquantity and characteristics of aircraft to be located in the voxel.

Although FIG. 4 shows example blocks of process 400, in someimplementations, process 400 can include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 4. Additionally, or alternatively, two or more of theblocks of process 400 can be performed in parallel.

Implementations described herein can divide airspace into airspacevoxels that each represent a three-dimensional portion of airspaceduring a particular time period. This can result in the creation ofthousands, millions, or more voxels. An airspace voxel can be associatedwith airspace parameters that represent conditions relating to flightthrough the airspace voxel during a particular time period. Theseairspace voxels and associated airspace parameters can be used toanalyze and provide recommendations regarding flight plans for tens,hundreds, thousands, millions, or more UAVs to consistently generatesafe, efficient flight plans. Such flight plans can be analyzed before aUAV flight, or can be generated in real-time via direct communicationwith the UAV while the UAV is in flight. In this way, a large quantityof UAV flight plans can be improved or optimized to increase flightsafety, reduce accidents, conserve UAV energy (e.g., battery power,fuel, etc.), reduce flight time, and/or the like.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise form disclosed. Modifications and variations are possible inlight of the above disclosure or can be acquired from practice of theimplementations.

As used herein, the term component is intended to be broadly construedas hardware, firmware, or a combination of hardware and software.

Some implementations are described herein in connection with thresholds.As used herein, satisfying a threshold can refer to a value beinggreater than the threshold, more than the threshold, higher than thethreshold, greater than or equal to the threshold, less than thethreshold, fewer than the threshold, lower than the threshold, less thanor equal to the threshold, equal to the threshold, etc.

Certain user interfaces have been described herein and/or shown in thefigures. A user interface can include a graphical user interface, anon-graphical user interface, a text-based user interface, etc. A userinterface can provide information for display. In some implementations,a user can interact with the information, such as by providing input viaan input component of a device that provides the user interface fordisplay. In some implementations, a user interface can be configurableby a device and/or a user (e.g., a user can change the size of the userinterface, information provided via the user interface, a position ofinformation provided via the user interface, etc.). Additionally, oralternatively, a user interface can be pre-configured to a standardconfiguration, a specific configuration based on a type of device onwhich the user interface is displayed, and/or a set of configurationsbased on capabilities and/or specifications associated with a device onwhich the user interface is displayed.

To the extent the aforementioned embodiments collect, store, or employpersonal information provided by individuals, it should be understoodthat such information shall be used in accordance with all applicablelaws concerning protection of personal information. Additionally, thecollection, storage, and use of such information can be subject toconsent of the individual to such activity, for example, through wellknown “opt-in” or “opt-out” processes as may be appropriate for thesituation and type of information. Storage and use of personalinformation can be in an appropriately secure manner reflective of thetype of information, for example, through various encryption andanonymization techniques for particularly sensitive information.

It will be apparent that systems and/or methods, described herein, maybe implemented in different forms of hardware, firmware, or acombination of hardware and software. The actual specialized controlhardware or software code used to implement these systems and/or methodsis not limiting of the implementations. Thus, the operation and behaviorof the systems and/or methods were described herein without reference tospecific software code—it being understood that software and hardwarecan be designed to implement the systems and/or methods based on thedescription herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of possible implementations. In fact,many of these features can be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below can directly depend on only one claim, thedisclosure of possible implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and can be used interchangeably with “one or more.” Furthermore,as used herein, the term “set” is intended to include one or more items(e.g., related items, unrelated items, a combination of related andunrelated items, etc.), and can be used interchangeably with “one ormore.” Where only one item is intended, the term “one” or similarlanguage is used. Also, as used herein, the terms “has,” “have,”“having,” or the like are intended to be open-ended terms. Further, thephrase “based on” is intended to mean “based, at least in part, on”unless explicitly stated otherwise.

What is claimed is:
 1. A device, comprising: one or more memories; andone or more processors, communicatively coupled to the one or morememories, to: receive information that identifies an airspace voxel thatrepresents a three-dimensional portion of airspace during a particulartime period; associate one or more airspace parameters with the airspacevoxel, the one or more airspace parameters representing one or moreconditions that relate to flight through the airspace voxel during theparticular time period; receive one or more flight parameters regardinga potential flight plan of an aircraft through a plurality of airspacevoxels, including the airspace voxel, during the particular time period,wherein the aircraft is an unmanned aerial vehicle (UAV); analyze theone or more flight parameters and a plurality of airspace parameters,associated with the plurality of airspace voxels, using one or moreairspace rules, wherein the plurality of airspace parameters includes agovernment regulation condition and another condition; and output arecommendation regarding the potential flight plan based on a result ofthe analysis.
 2. The device of claim 1, wherein the other conditionincludes one or more of: an environmental condition, a voxel occupancycondition, or other regulatory conditions.
 3. The device of claim 1,wherein the one or more flight parameters include one or more analysisparameters, the one or more analysis parameters including at least oneof: a risk tolerance associated with the UAV or the potential flightplan, a cost tolerance associated with the UAV or the potential flightplan, a time tolerance associated with the UAV or the potential flightplan, or a network tolerance associated with the UAV or the potentialflight plan.
 4. The device of claim 1, wherein the potential flight planis associated with a flight of the aircraft from a first location to asecond location; and wherein the recommendation includes a recommendedflight plan from the first location to the second location.
 5. Thedevice of claim 1, wherein the recommended flight plan is determinedbased on at least one of: a risk score determined based on analyzing theone or more flight parameters and the plurality of airspace parametersusing the one or more airspace rules, a cost score determined based onanalyzing the one or more flight parameters and the plurality ofairspace parameters using the one or more airspace rules, a time scoredetermined based on analyzing the one or more flight parameters and theplurality of airspace parameters using the one or more airspace rules,or a network score determined based on analyzing the one or more flightparameters and the plurality of airspace parameters using the one ormore airspace rules.
 6. The device of claim 1, wherein therecommendation includes at least one of: a rejection of the potentialflight plan, an approval of the potential flight plan, or a request foruser input to reject or approve the potential flight plan.
 7. The deviceof claim 1, wherein the one or more flight parameters and the pluralityof airspace parameters are based on an in-flight request received duringflight of the aircraft, wherein the in-flight request is received fromthe aircraft.
 8. A non-transitory computer-readable medium storinginstructions, the instructions comprising: one or more instructionsthat, when executed by one or more processors, cause the one or moreprocessors to: receive information that identifies an airspace voxelthat represents a three-dimensional portion of airspace during aparticular time period; associate one or more airspace parameters withthe airspace voxel, the one or more airspace parameters representing oneor more conditions that relate to flight through the airspace voxelduring the particular time period; analyze one or more flight parametersregarding a potential flight plan of an aircraft through a plurality ofairspace voxels, including the airspace voxel, during the particulartime, and a plurality of airspace parameters, associated with theplurality of airspace voxels, using one or more airspace rules, whereinthe plurality of airspace parameters includes a government regulationcondition and one or more other conditions; and output a recommendationregarding the potential flight plan based on a result of the analysis.9. The non-transitory computer-readable medium of claim 8, wherein theone or more other conditions are one or more regulatory conditionsregarding at least one of: a flight restriction in the airspace voxel, azoning law associated with the airspace voxel, a noise ordinanceassociated with the airspace voxel, or a privacy ordinance associatedwith the airspace voxel.
 10. The non-transitory computer-readable mediumof claim 8, wherein the one or more other conditions are one or moreenvironmental conditions regarding at least one of: weather in theairspace voxel during the particular time period, an amount of sunlightin the airspace voxel during the particular time period, or a time ofday during the particular time period.
 11. The non-transitorycomputer-readable medium of claim 8, wherein the one or more otherconditions are one or more voxel occupancy conditions regarding at leastone of: whether another aircraft is to be located in the airspace voxelduring the particular time period, a quantity of aircraft to be locatedin the airspace voxel during the particular time period, or a size,weight, or class of one or more aircraft to be located in the airspacevoxel during the particular time period.
 12. The non-transitorycomputer-readable medium of claim 8, wherein the one or more otherconditions are one or more ground conditions regarding one or moreobjects located on ground beneath the airspace voxel during theparticular time period.
 13. The non-transitory computer-readable mediumof claim 8, wherein the one or more flight parameters include at leastone of: a size, weight, or class of the aircraft, an airworthiness ofthe aircraft, a payload of the aircraft, an amount of noise generated bythe aircraft, or information associated with a pilot of the aircraft.14. A method, comprising: receiving, by a device, information thatidentifies an airspace voxel during a particular time period;associating, by the device, one or more airspace parameters with theairspace voxel, the one or more airspace parameters representing one ormore conditions that relate to flight through the airspace voxel duringthe particular time period; receiving, by the device, a plurality offlight parameters regarding a potential flight plan of an aircraftthrough a plurality of airspace voxels, including the airspace voxel,during the particular time period, wherein the aircraft is an unmannedaerial vehicle (UAV); analyzing, by the device, a plurality of flightparameters and a plurality of airspace parameters, associated with theplurality of airspace voxels, using one or more airspace rules, whereinthe plurality of airspace parameters includes a government regulationcondition and one or more other conditions; and outputting, by thedevice, a recommendation regarding the potential flight plan based on aresult of the analysis.
 15. The method of claim 14, wherein theplurality of flight parameters include one or more of: aircraftparameters, pilot parameters, or analysis parameters.
 16. The method ofclaim 15, wherein the recommended flight plan is determined based on atleast one of: a risk score determined based on analyzing the one or moreflight parameters and the plurality of airspace parameters using the oneor more airspace rules, a cost score determined based on analyzing theone or more flight parameters and the plurality of airspace parametersusing the one or more airspace rules, a time score determined based onanalyzing the one or more flight parameters and the plurality ofairspace parameters using the one or more airspace rules, or a networkscore determined based on analyzing the one or more flight parametersand the plurality of airspace parameters using the one or more airspacerules.
 17. The method of claim 14, wherein the recommendation includesat least one of: a rejection of the potential flight plan, an approvalof the potential flight plan, or a request for user input to reject orapprove the potential flight plan.
 18. The method of claim 14, whereinthe one or more other conditions include at least one of: a regulatorycondition, an environmental condition, a voxel occupancy condition, or aground condition.
 19. The method of claim 14, wherein the plurality offlight parameters include at least one of: a size, weight, or class ofthe aircraft, an airworthiness of the aircraft, a payload of theaircraft, an amount of noise generated by the aircraft, or informationassociated with a pilot of the aircraft.
 20. The method of claim 14,further comprising: receiving information indicating that the one ormore conditions that relate to flight through the airspace voxel havechanged; and altering the potential flight plan based on the informationindicating that one or more conditions that relate to flight through theairspace voxel have changed.